XML Server Controllers

The contents of this guid primarily apply to WebMaker Platform Edition, which includes everything in the Enterprise Edition and provides the additional benefits of XML Server Controllers. This Edition includes the Rules Designer and Runtime Platform, enabling you to natively map XML information flows between the front end and back end controllers. WebMaker Platform Edition enables you to create complete end-to-end enterprise applications, including leveraging of your existing databases and other common enterprise systems. Please note, if you are using a partner license such as BizFlow WebMaker, your license will cover all functionality up to and including the Platform Edition within the scope of that license. The WebMaker Platform provides a scalable environment for creating and hosting XML server controllers. XML controllers compliment the native XML data-binding capabilities for WebMaker applications and such controllers can be used to write native XML rules. Rules can be used for many purposes, including access to enterprise data stores, remote web services, business logic, etc. The WebMaker Studio contains features that can be used to create rules within the same graphical, drag-and-drop environment that is used for web page design and the Studio provides an integrated view of the overall application, from the client through to the server controllers and back again. The whole execution cycle can be visualised using the Debugger's tracing facilities. The collection of rules within a controller is often referred to as a RuleBase. The data within each controller, processed by the RuleBase is often referred to as the FactBase. Once all rules within a controller have been executed the resulting information is returned to the calling process, whether that is another controller or the web browser. Rules are based on an IF ... {condition} THEN ... {action} structure. Conditions are optional. You can open Rules Design tabs from the Application Map diagram by double-clicking the relevant Controller icon, or by using its right-click context menu option. You can also use the links against Form Submission and Ajax Submission actions in the Events tab, to open the rules for target controllers. Another option is to use the View Rules... link from the Debugger tab, which will show the Rules with the actual incoming runtime data on the left, and the outgoing data on the right. This displays the actual data, processed by the rules as the application executes in design mode (Run Test menu option). The screen below illustrates an example of a log entry viewed within the Debugger, showing the data on the left before the rule was processed, and the resulting output data on the right, that is the required format after rule processing. The following image illustrates the various components of controllers that work together to receive data, execute the rules and also orchestrate with other controllers and system components to build complete applications. Each controller uses an XML document for its working memory or data. The working memory is called the FactBase. This FactBase is constructed from the XML document initially passed to the controller and is retained in memory until rules processing is complete. It is then returned to the calling process or controller. The FactBase is updated as the rules are processed to reflect changes to the data. The FactBase can be altered by a range of available actions, including XSLT. The rendering of HTML pages is actually a transform of the XML data in the FactBase to HTML, before being sent to the Browser. Normally, the structure of the FactBase will be in the same format as the action submission binding structures. This is detailed under the Designing Web Pages documentation, within the Bindings Tabs section. As well as the main FactBase, each controller can define additional Variables, which can contain XML content. Whenever this documentation refers to querying or updating the FactBase, this can equally apply to Variables. Variables are only temporary documents that exist during rules processing. WebMaker rules generally manipulate XML data. WebMaker provides views for both the incoming data and outgoing data, as shown in the following screenshot. WebMaker will attempt to display relevant documents for you automatically. The general aim of the rules is to manipulate the data shown on the left so that it matches that shown on the right. When opening from the Debugger, you will see the actual data present at runtime. The exact information you see will depend on the type of log entry that was clicked. In this case, the information displayed is not permanently stored anywhere. You have the option to save the document for later use if required. Regardless of what documents are initially displayed, you can use the Change buttons to select a different document to display on either side to assist with the creation of your rules. XPaths are used to query and manipulate XML data. You can create XPaths by dragging elements from the XML Tree Views and dropping them into the required XPath text areas in the middle. XPaths can also be entered directly into the text areas, or edited after being constructed by the drag and drop operations. XPaths are typically validated as you type. More information on common XPath queries is available on forum entry: A Guide to Useful XPath Queries. WebMaker attempts to link the value to the current input and output documents. Next to each XPath, a count will be displayed indicating the number of elements the XPath matches in both documents. Clicking on either count will open that document, and highlight the elements that have been matched. This allows you to see if your XPath is selecting the elements within the documents, as intended. Note: If an XPath is evaluated, but the data does not match then there will be no highlighting. Sometimes XPaths may simply seek to determine the presence of elements, or that an element has a particular value.